home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001351_daemon _Fri Jun 18 13:58:03 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  7KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA27313; Fri, 18 Jun 93 13:58:07 MET DST
  3. Return-Path: <dsr@hplb.hpl.hp.com>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA27308; Fri, 18 Jun 93 13:58:03 MET DST
  6. Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA28328; Fri, 18 Jun 1993 14:20:15 +0200
  8. Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
  9.     id AA17014 (5.65b/CWI-2.225); Fri, 18 Jun 1993 14:20:08 +0200
  10. Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 18 Jun 93 13:11:53 +0100
  11. Received: by manuel.hpl.hp.com
  12.     (16.6/15.6+ISC) id AA29318; Fri, 18 Jun 93 13:18:04 +0100
  13. From: Dave_Raggett <dsr@hplb.hpl.hp.com>
  14. Message-Id: <9306181218.AA29318@manuel.hpl.hp.com>
  15. Subject: Re: HTML+ and Tables
  16. To: grobe@ukanaix.cc.ukans.edu
  17. Date: Fri, 18 Jun 93 13:18:01 BST
  18. Cc: www-talk@nxoc01.cern.ch
  19. Mailer: Elm [revision: 66.36.1.1]
  20.  
  21. This is in response to Michael Grobe's message of Tue, 15 Jun 1993
  22. ( Message-Id: <9306152358.AA37602@ukanaix.cc.ukans.edu> )
  23.  
  24. Dear Michael,
  25.  
  26. Comments on LINK and mailTo:
  27. ---------------------------
  28. > first, i mentioned that we are planning to use something like:
  29.  
  30. >      <link rev=made href="mailto:...whatever..." >
  31.  
  32. > to allow info providers to provide a path for readers (through their
  33. > clients) to contact them with comments.  note that this is a (static) "link"
  34. > rather than an (executable link, or) anchor, whereas your MSG tag is an
  35. > "executable" link.  lynx will support a command that will search out 
  36. > the static info and open a mail screen for the user with the address already
  37. > in place.
  38.  
  39. What do you mean by static link? Do you mean a browser menu option that lets
  40. users mail comments back to authors? Sounds like a good idea. How do you
  41. specify values for the subject and other header fields? I guess you could
  42. use the TITLE attribute for the subject, but that seems pushing the notation
  43. too far from its original concept.
  44.  
  45. {\begin aside}
  46.  
  47. While I think about it, the attribute "REV" and Tim's suggested values aren't
  48. particularly transparent. Perhaps HTML+ should use "REL" for relationship
  49. rather than "REV" (why "REV"?). Also "author" might be better than "made".
  50. What is the METHODS attribute intended for? Does anyone use it?
  51.  
  52. What are your views on the attributes for LINK?
  53.  
  54. {\end aside}
  55.  
  56. My latest version of the HTML+ DTD includes a FORM tag in place of MSG.
  57.  
  58.         <!ELEMENT FORM - - (MH*, (%main;|INPUT|SELECT)*)>
  59.         <!ATTLIST FORM
  60.             id      ID        #IMPLIED
  61.             action  %URL;     #IMPLIED>
  62.  
  63.         <!ELEMENT MH - - CDATA -- RFC 822 header fields -->
  64.  
  65. The idea is that you could have multiple forms in each document. The FORM
  66. tag acts as a wrapper for each form and defines the action to be take when
  67. the user presses the "commit" key.
  68.  
  69. By specifying a mailTo URL the form would be mailed to the designated
  70. person. The MH tag allows you to specify the mail headers is a more
  71. general way that would be possible with attributes to the FORM tag itself.
  72.  
  73.         <FORM action="mailTo:grobe@ukanaix.cc.ukans.edu">
  74.             <MH> Subject: comments on proposal
  75.             <INPUT id="f1">Your Comments</INPUT>
  76.         </FORM>
  77.  
  78. The presence of "mailTo:" in an LINK or A element would imply the need to
  79. pop-up an editor for the message with the appropriate header fields already
  80. filled in. The FORM element on the other hand creates the message itself.
  81.  
  82. If the action starts "http:...", the form would be sent as a query for
  83. this URL. The encoding of the forms contents would depend on the METHODS
  84. attribute and default to an id:value listing following a "?" suffix.
  85.  
  86. I still need to do some more work on the actual details of the encoding format,
  87. e.g. escaping white space and dealing with multiple values. In practice, it
  88. seems much nicer to define a new HTTP method for forms data, than to try and
  89. force it into the URL syntax.
  90.  
  91. Comments on Tables
  92. ------------------
  93.  
  94. I am getting uncomfortable about the detailed column specification format,
  95. e.g. it defines how wide the fields are without taking into account the width
  96. of the headers.
  97.  
  98. A better approach would be to let the browser work this out for itself.
  99. This fits in well with your suggestion for adding a placement attribute to
  100. specify center, left, or right justification. In the following I have
  101. used a separate tag for tables rather than overloading DL:
  102.  
  103.     <!ELEMENT TBL - - (TT?, TH*, TD*)>
  104.     <!ATTLIST TBL
  105.         id      ID        #IMPLIED
  106.         cols    CDATA     #REQUIRED -- number of columns --
  107.         compact (compact) #IMPLIED  -- if present use compact style --
  108.         border  (border)  #IMPLIED  -- if present draw borders -->
  109.  
  110.     <!ELEMENT TT - O (%text;)+ -- table title -->
  111.  
  112.     <!ELEMENT TH - O (%text;)+ -- column heading -->
  113.     <!ATTLIST TH
  114.         S   NUMBER  1           -- columns spanned --
  115.         L   (L)     #IMPLIED    -- left aligned --
  116.         C   (C)     #IMPLIED    -- center aligned --
  117.         R   (R)     #IMPLIED    -- right aligned --
  118.         D   (D)     #IMPLIED    -- decimal aligned -->
  119.  
  120.     <!ELEMENT TD - O (P|UL|OL|%text;)+ -- field data -->
  121.     <!ATTLIST TD
  122.         S   NUMBER  1           -- columns spanned --
  123.         L   (L)     #IMPLIED    -- left aligned --
  124.         C   (C)     #IMPLIED    -- center aligned --
  125.         R   (R)     #IMPLIED    -- right aligned --
  126.         D   (D)     #IMPLIED    -- decimal aligned -->
  127.  
  128. The above approach allows you to state <TD L> which is perhaps nicer
  129. than <TD A=Left>. The drawback is I don't know how in SGML to define several
  130. attributes as being mutually exclusive. *** What do you think? ***
  131.  
  132.  
  133.                   An Example of a Table
  134.     ___________________________________________________
  135.     |          |          average          | other    |
  136.     |          |   height    |     weight  | category |
  137.     |_________________________________________________|
  138.     | males    |    1.9      |      .003   | yyy      |
  139.     |_________________________________________________|
  140.     | females  |    1.7      |      .002   |      xxx |
  141.     ___________________________________________________
  142.  
  143.     <tbl cols="4" border>
  144.         <tt> An Example of a Table
  145.         <th> <th s="2"> average <th l> other
  146.         <th> <th> height <th> weight <th l> category
  147.         <td> males <td> 1.9 <td> .003 <td l> yyy
  148.         <td> females <td> 1.7 <td> .002 <td r> xxx
  149.     </tbl>
  150.  
  151. The browser works through the table to determine the types and widths of
  152. each field and how much room to allocate for each column. Using a fixed font
  153. for tables would speed things up a bit. By default headers are centred while
  154. text fields are left aligned. Numbers are vertically aligned on the units,
  155. making them harder to deal with.
  156.  
  157. How does that sound?
  158.  
  159. Dave Raggett